Note, this is an updated version of PR #3678

@olorinmaia, @Philoul @koelewij
Please consider this PR to continue our discussions

To my opinion this is a change with minimal impact. If users don't want the extra range, they can set the limits to such a value that they still have the old behavior.
On the high range just set the red limit to max.
For the lower side just set both the same, so there is only red and no yellow.

@koelewij Thank you very much for your comment!

@olorinmaia , @Philoul @koelewij Sorry to ping again. I am just wondering that you are ok with this PR (as you helped with/commented) the original PR #3678 already.

kind regards,
friedel

@vanmegen
Sorry, I didn't had time to test your PR until now.

• Reading comments and screenshots, a lot of work has been done to have the same BG colors everywhere, including into wizard and watch 👍

I will try to find time to test it to provide you my comments, but not sure very quickly 🥵...

Hi @Philoul,
thank you very much for your kind comments.

I just realized that I forgot to put screenshots for some additional places where the new UI displays blood sugar values

Insulin

Carbs

and the combination carbs/insulin dialog

kind regards,
friedel

I tested it on my dev phone, here are my different comments:
Concerning very low:

1. default value and minimum value should be set to 39 mg/dl (or 25 ???).

• AAPS don't manage values lower than 39 and I was surprised to see 25 as minimum in current OverviewLowMark double key, and 72 for default and not 70... (@MilosKozak an error or is it intended?)
• Default value for VeryLow should be aligned to the minimum value to not change default colors (by default very low override low if the very low value is above low value)

2. I think within User Interface Maximum value for VeryLow should be equal to the selected Low Value (and hardcoded within OverviewVeryLowMark (maxMgdl) to 72 (or 70) and not 160 mg/dl

• The user should not be able to select an higher value for very low compared to low, and same constraint for Very High that should always be above or equal high value

Concerning the Very High maximum and default value, it should be the maximum allowed value (I don't remember if it's 380 or 400 mgdl...)

By default, if this feature is included, it should be "transparent" for users: they will have enough new things just with the new UI, so I don't think we should add something additional visible. Then those who will want to adjust settings to see very high and Very Low will be able to adjust settings accordingly.

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Hi @Philoul

thank you very much for reviewing the code.

I tested it on my dev phone, here are my different comments: Concerning very low:

1. default value and minimum value should be set to 39 mg/dl (or 25 ???).

• AAPS don't manage values lower than 39 and I was surprised to see 25 as minimum in current OverviewLowMark double key, and 72 for default and not 70... (@MilosKozak an error or is it intended?)

• Default value for VeryLow should be aligned to the minimum value to not change default colors (by default very low override low if the very low value is above low value)

I updated core/keys/src/main/kotlin/app/aaps/core/keys/UnitDoubleKey.kt so that default values for very_high and very_low will result in the existing coloring scheme and boundaries (like, low values are read, high values are yellow if the very_* defaults are not changed.).

2. I think within User Interface Maximum value for VeryLow should be equal to the selected Low Value (and hardcoded within OverviewVeryLowMark (maxMgdl) to 72 (or 70) and not 160 mg/dl

• The user should not be able to select an higher value for very low compared to low, and same constraint for Very High that should always be above or equal high value

I agree that this sees to be a minor issue because the current logic will use the very_high value if it is set to a value that is smaller than the "high" value. As a result, the color/range of very_high will "win", i.e., the result would be what the user expected when setting the very_high config to a given value. (Same behavior for the very_low to "low" behavior).
I did some experiments to model this in the settings classes, but could not find an existing pattern to define constraints for min/max based on some other setting.

Concerning the Very High maximum and default value, it should be the maximum allowed value (I don't remember if it's 380 or 400 mgdl...)

Looking through code, I found that in the .js look, the boundaries are 39...401, for example in
...\app\src\androidTest\assets\OpenAPSSMB\determine-basal.js line 682

I updated the default to be 401.

As a side note, there was a limit in .../core/ui/src/main/kotlin/app/aaps/core/ui/compose/preference/PreferenceSliderWithButtons.kt that limits the number of steps to 200 which is too low in this case and prevented the slider from being drawn. I updated the maximum to 250.

By default, if this feature is included, it should be "transparent" for users: they will have enough new things just with the new UI, so I don't think we should add something additional visible. Then those who will want to adjust settings to see very high and Very Low will be able to adjust settings accordingly.

I agree. With the changes, the default behavior is as it is currently, i.e., range values are the same as well as colors for users that did not change the defaults previously. A user must actively change the values to see the additional ranges and coloring.